Various websites and applications enable users to control public or private settings for content. For example, a social networking application enables users to set a privacy setting for almost every “entity” relating to the application including, e.g., photos, videos, statuses, timeline/wall posts, etc. Consider an example where a user “Joe” of a social networking application attempts to view photos of another user “Jane.” Jane's photos can have different privacy settings to indicate whether all users can view the photos or only some users (e.g., public, friends, custom), and Jane can change those settings at any time. An authorization engine typically aggregates all of Jane's photos and/or other data relating to the photos from the backend servers where the photos are persistently stored to the web frontend servers where a set of privacy policies and rules are defined and/or evaluated. The authorization engine then evaluates each of the photos based on the set of privacy policies and rules. So, if Jane has 1000 photos, all of the photos would be fetched from the backend servers and evaluated at the web frontend servers. However, if for instance only 10% of the photos turn out to be viewable by the user Joe, 90% of the resources may have been wasted in retrieving the photos that could not be viewed by the user Joe.
One way to reduce the resources wasted in retrieving raw data that is eventually discarded is by implementing the authorization engine in the backend servers. However, the privacy policies and rules used by the authorization engine can be fairly complex and are typically defined in a computer programming language that is different from the computer programming language used at the backend servers. For example, the privacy policies and rules may be coded in PHP, while the backend servers may use C++. Consequently, the backend authorization engine cannot directly leverage the PHP-based privacy policies and rules and would require re-implementation of the privacy policies and rules in a computer-programming language suitable for the backend system. This means that any change to the privacy policies and rules would need to be made twice, first at the frontend and then at the backend, which results in a waste of resources. Instead of implementing the privacy policies and rules at two locations, one solution is to have the backend authorization engine check with the frontend privacy policies and rules for making privacy checks. However, such an implementation is also not desirable since the backend calls to the frontend for multiple users can quickly become inefficient and consume additional resources.